CSS3

The Webkit team have certainly been busy recently; since we mentioned the introduction of web fonts, they’ve also implemented transformations and animations.

Transformations, via the -webkit-transform property, allow you to scale, rotate and skew block elements; reader Ain Tohvri has put together an impressive test suite. At the moment this property doesn’t affect layout, so behaves more like a relatively positioned element.

Animation, which uses the -webkit-transition family of properties, allows you to set timings for fades, rotation, expansion, collapses, and more. They work in the same way as many current JavaScript libraries.

I’m in two minds about this; while it’s always welcome to see more innovation from browser manufacturers, I can’t help but think that they’re focussing their energies in the wrong direction. As I mentioned above, all of the above effects can be replicated with JavaScript libraries, and I don’t think that CSS should be used for controlling behaviour so explicitly. Users who don’t like to see animated pages currently have the option of disabling scripts, but they won’t have the option of disabling CSS in the same way.

Also, IMHO, there are a more pressing areas of CSS that need investigating; the Advanced Layout or Grid Layout modules are more important to the future of CSS than animations and transformations.

On the positive side, the Webkit team have promised to release technical documents which explain the proposed spec in detail.

If these new features float your boat, you can test them out by downloading the latest Webkit nightlies.

Too many people see the Web a bit like television: who ever heard of incompatible content? If there is an error, it’s because the TV set is broken, or maybe the antenna. On the Web, it is much more likely that the content is invalid, but try to explain that to users who just want to buy their holiday or see their bank account…

A very interesting interview with Bert Bos, on the history and future of CSS.

As we mentioned at the end of last month, the W3C have released a working draft of their first annual snapshot. The snapshots are intended to show which specs are stable enough to be considered part of the current state CSS.

The 2007 snapshot is:

• CSS Level 2 Revision 1
• Selectors Level 3
• CSS Namespaces
• CSS Color Level 3

The browser with the least support for the snapshot is, as you’ve probably already guessed, Internet Explorer. Opera has implemented all of the new selectors, but doesn’t yet have support for RGBA & HSL/A colours, which both the forthcoming Safari 3 (Webkit) and Firefox 3 (Gecko 1.9) have implemented. FF3 doesn’t do well with many of the new selectors, however, which Safari does.

While it would be nice to have included text effects and backgrounds & borders in this snapshot, differing browser implementations means they’re just not ready yet.

Even if this working draft becomes a recommendation shortly, no current or imminent browser fully supports the modules contained within; and with Firefox 3, Safari 3, and Opera 9.5 due for release over the next few months, it’s not impossible that none will do so until the latter half of next year. It could even be the case that IE.Next swoops in to beat the others!

With the CSS Eleven set to provide feedback to the W3C over the next few months, the 2008 snapshot could be a little more adventurous than that of 2007.

Here at css3.info we have a limited amount of resources, yet I’d like to push this site a little further then it’s already going, so I’m hoping you guys out there can help us out! What we need, are test cases for the different modules. The first that comes to mind, or actually was a request of Eric Seidel, Webkit developer: multi-column layout testcases.

Our current preview page doesn’t match the last version of the module, and browsers like Safari 3 are catching up, so we need more tests of it! If you make a testcase which we publish you will of course receive full credit for it in the footer of such a testcase.

The announcement of the formation of the CSS Eleven has caused quite a stir in the web development community, with a few questions raised over the self-appointed nature of the group and the way the announcement has been presented. One thing that everyone agrees on, however, is that there’s a clear and obvious need for their existence.

We spoke to Andy Clarke, respected designer and author, who announced the group’s formation (and explained it further here), and asked him a few questions about what we can expect from the CSS Eleven.

1. Please could you sum up very briefly for anyone who hasn’t read your introduction what the CSS Eleven is, and what you aim to do.

   One of the biggest challenges that the CSS Working Group faces is engineering solutions that meet the expectations of visual designers and developers. Leaving aside for a moment their other difficult tasks such as internationalization, understanding what designers need is a tough job; particularly as CSS gets more complex in the areas of layout, typography and other design related areas. The members of the working group, largely technical people, need help. They need practical help to understand what designers need, and in detail. This help cannot come simply from reading emails that are sent to them with suggestions. So far, the channels of communication between creative people and the CSS Working Group have been difficult and many people that I speak to feel that a new way needs to be found to get the designer’s voice heard and their needs understood.

   CSS Eleven is an informal group of visual designers and developers who have agreed to give up a little of their time to helping the CSS Working Group to understand what we need from CSS in the future. We will help by making suggestions, but more importantly by providing clear, real-world, visual, graphical examples of the results of the CSS that we need and helping with making test suites; two areas that have proven very time consuming in the past.

   Are we the only group that the Working Group will listen to? I hope not. We’re simply the first of what I hope will many ways that visual designers and developers get together to help make sure that CSS3 is what designers deserve it to be.

2. How will you arrive at the decisions as to which modules are most keenly needed?

   The decision to look at CSS Multi-Columns was purely mine as it is a mature draft with some features already available to test in some browsers. In the future I’m sure that efforts will be focussed on the modules that matter most to us as visual designers (personally, I’m particularly looking forward to seeing what happens with Advanced Layout). I’m sure that we’ll get lots of feedback and suggestions from the industry at large too.

3. Won’t it be hard to make judgements about implementation when there are no browsers available to test the more advanced features on?

   Of course implementation is important, and we would hope that the browser makers on the CSS Working Group will help us all they can by continuing to implement new features. For me as a visual designer, describing the features that I need from CSS visually is one of the most important jobs that I can do to help the development of CSS. We need clear, real-world visual examples from people who also understand CSS from an everyday working perspective. I’m sure that with so many great people volunteering, there will be plenty to work on.

4. What kind of timescale are you looking at for releasing the first batch of recommendations?

   I would think that we will two months working collaboratively on CSS Multi-Columns, after which I expect that we will open the wiki (or some similar facility) to a wider audience for a month before wrapping things up and handing it to the CSS Working group. Of course everybody involved is volunteering some of their valuable time, so time-scales may change.

5. Which aspect of CSS 3 are you personally most looking forward to?

   Grid Positioning and Advanced Layout will help to solve many of the problems that designers face every day using CSS. There has been a little confusion about the role of Grid Positioning and its relationship to Advanced Layout, but both are exciting developments that I am looking forward to seeing.

Kornel mailed me today with an addition to the text-shadow preview page, that looks quite good :). He noted that the Safari implementation of text-shadow is a bit poor, as it supports only one shadow, and they are offset wrong by 1px. Thanks Kornel!

If you have any additions or new preview pages, feel free to contact us!

The latest Webkit builds now support an open implementation of the @font-face rule, which we wrote about some time ago. Recent articles by Håkon Wium Lie had indicated that Opera might be first to market with this, but the Webkit team seem to have beaten them to it.

In short, @font-face allows you to download fonts to the visitor’s browser, meaning you can use any licensed font to display your pages. An example of use would be:

@font-face {
font-family: 'The New Font';
src: url('http://www.example.net/newfont/');
}

It’s a step forward for the web, and I’m delighted it’s here. Congratulations to the Webkit team, and here’s hoping that Opera push forward with their plans to implement it too. It seems like Firefox 3 won’t support this rule, so late 2008 may be the earliest we see this in Mozilla browsers.

As for Internet Explorer, they’ve actually implemented @font-face since version 4! However, it only works with their proprietary font format, .eot, and never took off. I wonder if they will reimplement it with Open- or True-Type fonts now.

@font-face isn’t actually new in CSS 3, it’s been around since CSS 2. However, as it’s never been properly introduced I think it’s okay to include it here!

The CSS Working Group recently met face-to-face in Beijing, and have released a series of notes about some of the issues they discussed regarding the current and future states of CSS.

One interesting possibility that was raised is to allow rotation of page elements; according to the original proposal, these are some of the possible use cases:

1. rotate a block of text 90 degrees as for a tab on left of page
2. rotate an image (or block of text) an arbitrary amount
3. use rotated column headings for narrow table columns

It must be stressed that this exists purely as an idea at the moment, so we won’t be seeing it any time soon. Still, it would create many new possibilities in web design.

Following our discussion of the inherent ambiguity in the border-radius declaration, it has been decided that the simpler syntax used by Mozilla will used for the shorthand; that is, in order to apply elliptical corners on elements, you will have to declare them all separately. I think this is a good decision, and I’m delighted that the CSSWG have listened to the views of the community. A pat on the back for everyone involved!

Finally, the CSSWG are to release an annual(?) snapshot of modules considered stable, in order that browser makers and developers can begin to implement them. The 2007 snapshot will include:

• CSS2.1
• Selectors
• CSS3 Color
• CSS Namespaces

The 2008 version is likely to include Paged Media and Media Queries, and possibly Ruby and Backgrounds and Borders.

So that’s the state of CSS today. Interesting stuff; many thanks to the CSSWG for making it all public.

Until the Advanced Layout and Grid Layout modules are implemented, we have to get by with the existing tricks of the trade. One of those is the use of faux columns, a background image which simulates equal-height columns. This is a good technique, but the drawback is that it only works with fixed-width columns.

That problem was overcome with the advent of liquid faux columns, which uses some background-position trickery and a bit of maths to create a variable-width effect.

With the (tentative) introduction of background-size in Safari and Opera, however, faux columns are about to become a lot easier; all you need to do is create a background image and assign a percentage value to background-size, allowing the image to expand or contract with its containing box.

Take a look at this example (only tested in Safari 3 and Opera 9.5; may work in Konqueror 3.5.7 also). If you resize your browser window, the text and columns should maintain their proportions.

The way this is done is with a simple PNG image; I’ve made it 1000px wide, with two coloured columns of 250px each, so that it’s easier to calculate column widths (25%,50%,25%).

I’ve set this as the background-image on the html element, which has been assigned a width of 90%. Inside this there is a container div with a width of 100%, and my three columns with the widths set at the same ratio as the background image:

<div id="container">
	<div id="one">
	</div>
	<div id="two">
	</div>
	<div id="tre">
	</div>
</div>

#container {
position: relative;
width: 100%;
}
#one {
margin: 0 25%;
}
#two, #tre {
position: absolute;
top: 0;
width: 25%;
}
#two { left: 0; }
#tre { right: 0; }

The html element has the background-size declaration applied to it, with a percentage value to make it liquid, using the browser-specific prefixes followed by the proposed declaration (for safety):

html {
background-image: url('opera_bg.png');
-khtml-background-size: 100%;
-o-background-size: 100%;
-webkit-background-size: 90%;
background-size: 100%;
background-position: 50% 0;
background-repeat: repeat-y;
width: 90%;

You’ll notice that the Webkit value is different from the others; during this test, it seems that Webkit obtains its width from the entire browser window, not from the containing element; therefore, we have to set this value to be equal to the width of the containing element. I haven’t tested this thoroughly yet, so I’m not sure if this is a persistent bug or if there’s something I’m doing wrong. Anyway, Opera 9.5 behaves as expected.

After that I’ve added the background-position and background-repeat declarations; background-repeat to tile the image down the page, and background-position because Webkit seems to ignore the margin values and puts the image at top left of the browser window; this is only necessary if you’re centre-aligning your page.

Apart from a little tidying up, that’s it; once the module becomes a recommendation and the browser-specific prefixes are dropped, it will require only a few lines of code for the simple effect. In the meantime, remember that this is for experimentation purposes only and shouldn’t be used in a live environment. This is just a sketch of the technique at the moment, and requires more testing.

CSS3 now has a new proposal for laying out websites, with the release of the first working draft of the grid positioning module. The new module makes it easier to define layouts using typographic grids (see Khoi Vinh’s website for a good introduction).

Used in conjunction with the multi-column layout module, you can use the new gr measurement unit to define objects that span multiple columns:

body { columns:3; column-gap:0.5in; } 
img { float:page top right; width:3gr; }

Or, using the new grid-columns and grid-rows declarations, you could quickly divide up a page for layout purposes:

body { grid-columns: * * (0.5in * *)[2];
grid-rows: 20% *;
columns:3; column-gap:0.5in; }

I’ve only had the chance for a cursory look at this so far, but it strikes me that it’s not quite as intuitive as it could be, although I need to have a proper look before I can put my finger on exactly why. However, it’s a nice attempt by the W3 to solve the problem of print-style layouts, and after further revision I’m sure it will be a welcome addition.